(1) Field of the Invention
The invention pertains generally to captive portals. More specifically, the invention relates to a DNS-based captive portal with integrated transparent proxy to protect against a user's device caching an incorrect IP address.
(2) Description of the Related Art
The term “captive portal” generally refers to any technique that automatically forces a client device running a web browser to display a specially designated web page before being permitted to access a network such as the Internet in a normal manner.
Captive portals are often utilized in situations where it is required to force new users to view a login portal. For example, before allowing a guest in a hotel to surf the Internet, the guest may be required to log in at the hotel's login portal for billing and/or authentication purposes. Although it is possible to simply instruct users to manually navigate to a special Uniform Resource Locator (URL) or Internet Protocol (IP) address such as by placing instructional cards or brochures near network connection ports in the hotel room, a typical hotel guest would not read these instructions and instead expect the process to be fully automatic. A more user-friendly design presents the user with the login portal regardless of what web site the user may first try to load.
A known type of captive portal involves a domain name system (DNS) server resolving all domain names for unlogged in user devices to the IP address of a login portal. Essentially, the captive portal is performing DNS poisoning so that domain name requests from unlogged users are always resolved to the IP address of the hotel's login portal instead of the proper IP address of the requested website on the Internet. After the user device has logged in, the DNS server will begin to properly resolve domain name requests from the user device to their correct IP addresses using standard DNS techniques.
A first problem with a DNS-based captive portal is it will only work if the user initially attempts to browse to a URL with a domain name address and will not work if the user attempts to connect to a URL with a specific IP address. For example, if a non-logged in user at a hotel attempts to browse a website such as “http://5.6.7.1/index.html”, unless the specified IP address matches that of the hotel's login portal, the user will not see the login portal. There is no way via the DNS protocol to cause the browser on the user's computer to display the login portal if the user device does not attempt to perform a domain name lookup.
A second problem with deliberately performing DNS poisoning for unlogged in user devices is that the user devices may cache the IP address of the login portal even after they are logged in. For example, if an unauthorized user device attempts to browse the website “example.com”, the DNS server will provide the IP address of the login portal, for example, 192.168.1.1 because the user device is not yet logged in. After successfully logging in, when the user again attempts to browse the external website at “example.com”, the user's device may directly attempt to connect to 192.168.1.1 without performing a new DNS query because the user device has cached this incorrect IP for the domain name “example.com”.
A known solution to this problem involves configuring the DNS server of the captive portal to provide a low time-to-live (TTL) such as zero seconds when resolving domain names to the IP address of the login portal for unauthorized user devices. The TTL informs the user device of the time duration for which the provided IP address will be valid. Once the time duration specified by the TTL for a particular domain name expires, the user device should re-perform a DNS lookup for the next operation requiring the IP address of that particular domain name.
In theory, setting the TTL to zero seconds should completely prevent the user device from caching an incorrect IP address. However, in practice, there is no guarantee the user device will respect the TTL. Even if the underlying operating system on the user device does respect the TTL for a DNS-provided IP address, some applications running on the user's computer may keep their own cached IP addresses and not respect the TTL. For example, a web browser on the user device may cache mappings of domain names to IP addresses to avoid making repeated internal requests to the operating system running on the user device. Such caching action by the browser increases the speed at which websites render; however, it causes problems in a DNS-based captive portal because the browser may continue to connect with the IP address of the login portal for URLs involving domain names that were requested prior to successful login. In other words, for URLs requested prior to successful login, the browser will continue to display to the login portal even after the user has successfully logged in. To solve this problem, a user needs to either 1) wait some period of time until the browser automatically clears its internal cache of DNS-provided IP addresses, or 2) close and restart the browser, which will generally startup in a fresh state without any cached IP addresses.